You've added a new chrome.runtime.onMessage.addListener. However, this file now contains multiple onMessage listeners (e.g., another one starts on line 169, and more follow). Registering multiple listeners for the onMessage event is an anti-pattern in Chrome extension development and can lead to unpredictable behavior, race conditions, or messages not being handled as expected. Only one listener should be active for the runtime.onMessage event.

It's highly recommended to consolidate all message handling logic into a single chrome.runtime.onMessage.addListener block, using if/else if or a switch statement to delegate based on request.action.

Example of consolidation:

chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
    switch (request.action) {
        case "getTabs":
            // ... logic for getTabs
            return true; // Indicate async response
        case "getTabsWithContent":
            // ... logic for getTabsWithContent
            return true; // Indicate async response
        case "setCookie":
            // ... logic for setCookie
            return true; // Indicate async response
        // ... other cases
        default:
            // Optional: handle unknown actions
            break;
    }
    return false;
});

Is this something that should be fixed Luca? This problem predates my tabs feature, so I assume you did this intentionally...

Using an inline onclick attribute is generally discouraged. It's better practice to attach event listeners programmatically using addEventListener. This improves separation of concerns (HTML structure vs. JS behavior) and makes the code more maintainable. A possible implementation would be to add an ID to the button, append the errorDiv to the body, then find the button by its ID and add the click listener. This also applies to the showNoTabsError function.

Similar to the showDatasetTooSmallError function, using an inline onclick attribute is discouraged. It's better practice to attach event listeners programmatically using addEventListener. This improves code maintainability and separation of concerns.

This return false is incorrect and can break other message listeners. In a Chrome extension's onMessage listener, you should only return true if you are sending a response asynchronously. If a message is not handled by this listener, it should have no explicit return (which defaults to undefined) to allow other registered onMessage listeners to process the message. Returning false can prematurely close the message port for other listeners that might need to send an asynchronous response, which could break existing functionality.

This file now contains multiple chrome.runtime.onMessage.addListener calls. While this can work, it's an error-prone pattern that is hard to maintain and can lead to unexpected behavior if a listener doesn't correctly return true/false. A more robust and common pattern is to use a single onMessage listener that acts as a dispatcher, routing messages to the correct handler based on request.action (e.g., using a switch statement). I recommend refactoring to consolidate all message handling into a single listener.

These chained replace calls are redundant. The \s character class already includes spaces, newlines, and tabs. You can simplify this to a single replace call for better performance and readability.

        allText = allText.replace(/\s+/g, ' ').trim();

The number 3 here is a magic number, making it unclear what this threshold represents without more context. It's better to extract it into a named constant (e.g., MIN_TABS_FOR_SPACE_CREATION) to improve readability and make it easier to modify in the future.

Handling errors by checking for substrings in the error message is brittle. If the error messages change, this logic will break. It's more robust to use custom error classes. For errors thrown within this file (like 'No tabs found' and 'Not enough tabs'), you can define and throw custom error classes and then check for them in the catch block using instanceof.

The extractedData parameter is typed as any[]. To improve type safety and code clarity, it's better to define a specific interface for the objects in this array. You could define an interface like this at the top of the file:

interface ExtractedTabData {
  title: string;
  semantic_title: string;
  link: string;
  snippet: string;
}

Then you can use ExtractedTabData[] as the type for extractedData here and where it's initialized in createSpace.

This function uses innerHTML and an inline onclick handler to create a UI element. This is not recommended due to potential security vulnerabilities (XSS) if the data were to come from an external source, and it makes the code harder to maintain. It's better to create DOM elements programmatically and attach event listeners using addEventListener. This advice also applies to the showNoTabsError function.

handled, will commit in a few

The query selector "#hdtb-sc > div > div > div.crJ18e" is very specific and relies on the current DOM structure and CSS classes of the Google search page. This is brittle and likely to break if Google updates their page design. If possible, try to find more stable selectors, like ones based on IDs, data-* attributes, or ARIA roles. If not, it's worth adding a comment to acknowledge this fragility. This also applies to other selectors in this file, like on line 264.